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I. 



REAL PARTY IN INTEREST 

Pitney Bowes Inc. is the real party in interest. 



II. RELATED APPEALS AND INTERFERENCES 

There are no related Appeals and interferences. 



III. STATUS OF CLAIMS 

a) Claims 1 -7, 9 -15 and 17 

b) Claims 1 -7, 9 -15 and 17 
d) Claims 1 -7, 9 -15 and 17 

IV. STATUS OF AMENDMENTS 

No Amendment subsequent to th 
entered. 



27 are in the application. 
27 are rejected. 
27 are on appeal. 

Final Rejection of April 17, 2006, was 



V. SUMMARY OF CLAIMED SUBJECT MATTER 

A. Background 

Prior art methods did not provide for balancing the load of 
requests from a plurality of network devices for service from a 
selected one of a plurality of service providers; and a network 
connecting the devices and service providers, and a network 
device programmed to carry out the method. 

The subject invention relates to communication on a network among a 
plurality of devices requesting service and a plurality of service providers. 
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More particularly, it relates to balancing the load of service requests among 
the service providers. 

It is common for devices on a network to request required services from a 
service provider on the network. Such services may be any type of data service 
that is more readily carried out by a remote service provider, such as updating of 
databases, downloading software, remote diagnostics, or computationally 
intensive operations. 

In networks where there is a heavy volume of service requests from a 
large number of devices, having a number of service providers capable of 
providing the requested services on the network generally will provide better 
response, increase reliability, and be more economical than providing a single 
service provider capable of handling peak loads. Such networks will be more 
effective if some mechanism for "load balancing" is provided. By "load balancing" 
herein is meant distributing requests for service substantially uniformly over the 
service providers on the network. Heretofore, load balancing typically has been 
carried out by directing all requests to a central site, which would direct the 
request to one of the service providers. 

While effective this method has certain disadvantages. The increase in 
network traffic to route all requests through a central site may cause a 
corresponding increase in response time. It is known for some load balancers to 
redirect a device that uses that address until the connection completes. In this 
way, the load balancer is only affected by the traffic from devices at the start of 
connection. Often there is more than one load balancer in the network so that if 
the primary fails, the backup is discovered (by way of Domain Name Services 
alternates) and used. Also, such load balancing mechanisms will route requests 
based on the network address of the requesting device, which may not reflect the 
actual geographic location of the requesting device and may result in requests 
being serviced by a geographically remote service provider. (It is believed that 
the optimum service provider generally will be the geographically closest 
available service provider.) For these and other reasons, some networks do not 
provide load balancing. 

V 
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It is noted that there are load balancers that operate at the ends of a 
network, but to be effective, they need to operate over a majority of network 
endpoints. For small to medium applications, such as Internet appliances that 
only very occasionally connect, this means this type of load balancing is not cost 
effective. 

Thus, it is an object of the subject invention to provide a more effective 
and simpler method for load balancing on a network, and a device capable of 
carrying out that method, and a network incorporating such devices. 

B. Appellant claims a method that assesses a table to 
retrieve a service provider address associated with a service 
provider location code geographically closest to a retrieved 
location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographic 
location of the client. 
The claimed invention balances the load of requests from a plurality of 
network devices for service from a selected one of a plurality of service 
providers; and a network connecting the devices and service providers, and a 
network device programmed to carry out the method. Devices and service 
providers communicate over the net in any convenient manner; which can 
include any of numerous known network architectures and compatible protocols. 
In accordance with the subject invention, each of the devices stores a location 
code indicative of geographic locations of the devices and stores a table relating 
geographic location codes and network addresses for the service providers. 
Each of the devices is programmed so that a requesting device initiates a 
request by: 1 ) retrieving the location code for the requesting device; 2) accessing 
the table to retrieve a service provider address associated with a service provider 
location code closest to the retrieved location code; and 3) addressing the 
initiated request with the retrieved service provider address. 

In accordance with a broad aspect of the subject invention, the network 
device can carry out any convenient function and the service providers can 
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provide any convenient function. The network device may be any device which 
may know as a matter of its operation, its geographic address. 

In accordance with another aspect of the subject invention, the network 
device is a mailing device. 

In accordance with another aspect of the subject invention, at least an 
approximate distance between two geographic locations can be calculated as a 
function of location codes corresponding to the two locations. 

In accordance with still another aspect of the subject invention, devices 
access the table to retrieve another service provider address associated with a 
service provider location code next closest to the retrieved location code if they 
cannot log on to the service provider 

Other objects and advantages of the subject invention will be apparent to 
those skilled in the art from consideration of the detailed description set forth 
below and the attached drawings. 

Claim 1 is the only independent method claim in this patent application 
that is on appeal. Claim 1 is a method for balancing the load of requests from a 
plurality of network devices for service from a selected one of a plurality of 
service providers, the devices and the service providers being interconnected by 
a network. The method comprising the steps of: 

a) in each of said devices, storing a location code indicative of 
geographic locations of said devices; 

b) in each of said devices, storing a table relating geographic 
location codes and network addresses for said service providers; and 

c) said devices being programmed so that a requesting device 
initiates a request by: 

c1 ) retrieving said location code for said requesting device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographical location of the 
client 
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c3) addressing said initiated request with said retrieved 
service provider address; and 

d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

Appellants claimed invention is shown in Fig. 1 and Figs. 3A and 3B, 
which are described in page 4, line 17 to page 6, line 7 and page 7, line 11 - 
page 10, line 22 of Appellants' Patent Application. A copy of Fig.1 appears next 
to this page. 

Figure 1 shows a plurality of network devices 10 connected by data links 
12 to a communications network and a plurality of data centers 30 connected to 
network 20 by communications links 14. Data centers 30 include service 
providers 32A and 32B (hereinafter sometimes referred to generally as service 
providers 32) which provide services to network devices 10. In general, devices 
10 can carry out any convenient function, and service providers 32 can provide 
any convenient service, such as updating of data bases, downloading of 
software, off-line computationally intensive operations and diagnostics. (It should 
be noted that, while various network devices 10 can have different functions and 
various service providers 32 can provide different services, their operations and 
functions are substantially identical in balancing the load created by requests for 
service in accordance with the subject invention.) In a preferred embodiment of 
the subject invention, network devices 10 include mailing devices, such as 
postage meters and rating scales, which determine postage amounts or shipping 
charges for mail pieces or packages to be shipped. Comprising of such mailing 
devices in a system in accordance with the subject invention is believed to be 
advantageous in that it is inherently beneficial to provide communications with a 
service provider; postage meters can more easily keep track of funds equivalents 
and rates used by scales can be easily updated. Further, mailing devices 
inherently must store the zip code of their geographical location. (Scales 
compute rates as a function of the origin zip code and the input destination zip 
code and, so, are initially programmed with the zip code of their geographic 
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location. Postage meters, on the other hand, are required to be used at a 
particular location and to store the zip code of that location. The importance of 
the zip code of the location at which the device is used will be explained more 
fully below.) 

The preferred embodiment of the subject invention also includes other 
network devices, such as consumer appliances (refrigerators and the like) that 
communicate over a network, such as the Internet. Such consumer appliances 
may be candidate devices for this system inasmuch as they can be made aware 
of their location to fulfill warranty requirements. Also, cellular telephones with 
Internet interfaces which have a mandate to provide geographic location by the 
Federal Communications Commission, as well as devices on wireless networks, 
such as Mobitex (used by, for example, the Palm™ VII), which provide the 
address of the base station servicing the wireless device, are candidates for the 
present invention. 

Figure 3A appears next to this page. 

Figures 3A and 3B show a flow diagram of the operation of device 10 in 
accordance with relevant portions of the program code to request service from a 
service provider. At 40, device 10 retrieves the previously stored location code, 
which in a preferred embodiment will be a zip code but which can be any 
convenient code. As noted above, where device 10 is a postage meter, postal 
regulations require that it store the zip code of the post office at which the 
metered mail must be deposited (which is presumed by the system to be 
geographically close to the meter). Where device 10 is a rating scale, the scale 
requires a local zip as well as a destination zip to compute costs for distance 
("zone") sensitive rates. Thus, the zip code for the geographic location of such 
devices will be readily available. Other methods for establishing the location 
code for device 10 are also within the contemplation of the subject invention. 
Such methods can include, without limitation, input by the device operator, input 
during installation or set-up, down loading through network 20 in response to a 
communication, either on-line or off-line. For example, an off-line communication 
can be receipt of a warranty card, which would include the location of device 10 
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so that service can be efficiently dispatched. Where device 10 is a mobile 
device, it can include a Geographic Positioning System (GPS) to monitor its 
location. As previously stated, where device 10 is a mobile device, the base 
station servicing the device may furnish its fixed geographic location. 

At 42, device 10 accesses table 10-1-2. Each record in table 10-1-2 
relates the location code of a service provider and its network address. 
Preferably, the location codes are so designed that at least an approximate 
distance between device 10 and one of service providers 32 can be analytically 
computed from the respective location codes. An example of such conversion, 
referred to as "zip-to-zone" conversion, is described in U.S. Patent No. 
4,122,526, titled CALCULATING AND POSTAL ZIP CODE-TO-POSTAL ZONE 
CONVERTING APPARATUS. Where location codes are fully analytical so that 
at least sometimes distances cannot be computed, look-up tables can be 
provided. Device 10 then determines the network address of the closest service 
provider. 

At 46, device 10 then determines if the address is valid. For example, an 
invalid address can be indicated by receipt of a "fatal address error" message. 

If the address is invalid, at 50, device 10 obtains an address for seed 
system 34, which communicates through network 20 over communications link 
16, and at 52 logs on to system 34 to download a current table. Seed system 34 
can be a dedicated system or can be a designated one of service providers 32. 
Device 10 would be programmed at the factory with the seed address. If the 
seed address changed, device 10 can obtain the new seed system address in 
any convenient manner such as, for example, having an operator place an off- 
line service call to obtain the address and enter it through interface 10-4. Device 
10 then returns to 42 to obtain a service provider address from the current table. 

If the address is valid, at 54, device 10 attempts to log on to the selected 
one of service providers 32, and, if the log on is determined successful at 58, at 
60 sends a service request to that provider and exits. 

In a preferred embodiment of the subject invention, two of service 
providers 32 may share the network address of a data center 30. Devices 10 will 
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be assigned to one of service providers 32 at center 30 as primary, and to the 
other as alternate, in any convenient manner. For example, devices 10 with 
even serial numbers can be assigned to service provider 32A as primary while 
devices 10 with odd numbers are assigned to service provider 32B. 

Thus, if the log-on attempt is determined unsuccessful at 58, at 62 device 
10 attempts to log on to the alternate one of service providers 32, and, if the log 
on is determined successful at 66, at 60 sends a service request to the alternate 
provider and exits. 

Figure 3B appears next to this page. 

If the log-on attempt is determined unsuccessful at 66, at 68 device 10 
returns to the table to search for the next closest one of service providers 32. 

If at 70 device 10 determines that another service provider has been 
found, then at 74 device 10 attempts to log on to its primary one of service 
providers 32, and, if the log on is determined successful at 76, at 60 sends a 
service request to the alternate provider and exits. If the log-on attempt is 
determined unsuccessful at 76, at 78 device 10 attempts to log-on to the 
alternate one of service providers 32 at the closest (and now current) network 
address, and, if the log on is determined successful at 82, at 60 sends a service 
request to the alternate provider and exits. If device 10 is unsuccessful in 
logging on, then at 82, it returns to 68 to search the table again. When at 70 no 
service provider address can be found, device 10 sends an error message and 
exits, or exits to some other convenient error routine. 

Thus, it can be seen that the subject invention will efficiently balance the 
load of service requests on the network by assigning each request to the 
available service which is geographically closest, without requiring a central cite 
or other network hardware or software to assign requests. It is believed that the 
subject invention will thus, substantially reduce network complexity and traffic 
flow relating to load balancing. This scheme reduces the need for central load 
balancing equipment to the point where a simple system distributes new address 
tables only to those devices that do not have accurate tables. The devices are 
systematically load balanced across service providers geographically closest and 
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further statistically load balanced to specific systems at those geographically 
close service provider sites. The potential for load balancer failure is eliminated 
inasmuch as no load balancers exist in the described system. Initial connection 
times are enhanced, because there is no need for initial redirection. Finally, this 
system is compatible with numbered addressing systems such as Internet 
Protocol (IP) addresses directly and does not rely on the complexity of resolving 
Universal Resource Locators (URLs) or other such names. This simplifies device 
design and construction. 

Claim 9 is the first of the two apparatus claims in this patent application 
that is on appeal. Claim 9 is a network device, for receiving service from a 
selected one of a plurality of service providers when the device and the service 
providers are interconnected by a network. Thesaid device comprising: 

a) a first data store storing a location code indicative of said 
device's geographic location; 

b) a second data store storing a table relating geographic location 
codes and network addresses for said service providers; and 

c) said device being programmed to initiate a request by: 

c1 ) retrieving said location code for said device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographic location of the client; 

c3) addressing said initiated request with said retrieved 
service provider address; and 

d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

Claim 9 is shown in Fig. 1 and Figs. 3A and 3B, which are described in 
page 4, line 17 to page 6 line 7 and - page 7 line 11 - page 10 line 22 of 
Appellants' Patent Application, which has been set forth above. 
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Claim 17 is the second of the two apparatus claims in this patent 
application that is on appeal. Claim 17 is a network that comprises a plurality of 
network devices and a plurality of service providers, the devices receiving service 
from selected ones of the service providers when the devices and the service 
providers are interconnected by the network,. The devices each comprising: 

a) a first data store storing a location code indicative of that 
device's geographic location; 

b) a second data store storing a table relating geographic location 
codes and network addresses for said service providers; and 

c) each of said devices being programmed to initiate a request by: 

c1) retrieving said location code for said device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographic location of the client. 

c3) addressing said initiated request with said retrieved 
service provider address; and 

d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

Claim 17 is shown in Fig. 1 and Figs. 3A and 3B, which are described in 
page 4, line 17 to page 6 line 7 and - page 7 line 11 - page 10 line 22 of 
Appellants 1 Patent Application, which has been set forth above. 

VI. GROUNDS OF REJECTION 

A. Claims 1 , 9, and 17 have been rejected by the Examiner under 35 
USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 6,078,960) in 
view of Swildens et. al. (U.S. Patent No. 6,484,143) and further in view of Zisapel 
et al. (US Patent No. 6,665,702). 
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B. Claims 6-7, 1 3-1 5 and 21 -24 have been rejected by the Examiner 
under 35 USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 
6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,484,143). 

C. Claims 2, 10 and 18 have been rejected by the Examiner under 35 
USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 6,078,960) in 
view of Swildens et. al. (U.S. Patent No. 6,484,143) and further in view of Leon 
(U.S. Patent No. 6,424,954) 

D. Claims 3, 1 1 and 1 9 have been rejected by the Examiner under 35 
USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 6,078,960) in 
view of Swildens et. al. (U.S. Patent No. 6,484,143) and further in view of 
Rabinovich (US Patent No. 6,256,675). 

E. Claims 5, 13 and 21 have been rejected by the Examiner under 35 
USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 6,078,960) in 
view of Swildens et. al. (U.S. Patent No. 6,481,143) and further in view of Rune 
(US Patent No. 6,304,913). 

VII ARGUMENTS 

A. Claims 1, 9, and 17 have been rejected by the Examiner under 35 
USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 
6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,484,143) and 
further in view of Zisapel et al. (US Patent No. 6,665,702). 

Ballard discloses the following in column 6 lines 31-64; 

"Referring to FIG. 6, a method for client-side load balancing 
includes a step 50 in which a client computer 14 requests 
to access data over the client-server network 10. At 
another step 52, the client computer 14 executes a server 
selection function to determine which server 12 to access. 
A processor 28, for example, reads the load balance list 54 
resident on the client computer 14. The server selection 
function determines which server identified in the list 54 is 
to be accessed to handle the pending data request. For an 
embodiment in which there is a load percentage included in 
the list 54, such percentages are seeds for the server 
select function. Over time as the server select function is 
executed over and over, the actual load percentage for 
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each server computer in the list 54 converges to the 
specified percentage in the list 54. According to an 
alternative scheme, the load select function may randomly 
select one of the servers in the list 54 or perform a round- 
robin selection, or perform some mathematical 
computation. 

Once a server is selected, at step 56 a network connection 
is attempted to connect the client computer 14 to the 
selected server computer 12. At step 58 the connect 
operation is tested to determine if successful. If the 
connection is successful, then at step 60 the data is read 
from the server computer 12 and downloaded to the client 
computer 14. In addition, during each connection or at 
regularly determined times or connections, an updated load 
balance list also is received from the accessed server 
computer 12. The updated list replaces prior load balance 
list stored at the client's computer 14. As shown in FIG. 4B 
the updated load balance list may add an additional server 
and alter the load balance percentages. Alternatively, the 
updated list may remove a server or just alter the load 
balance percentages. Thus, one or more servers can be 
added or removed and load balance percentages can be 
altered." 

Ballard discloses the following in column 6 lines 3-18; 

"Each client computer 14 stores a load balance list. 
Referring to FIG. 4A, in one example, common data is 
stored on each of ISP servers 1-4. The load balance list 
includes an identification of the server computers, such as 
an address. In some instances the list also include a 
respective load percentage for each of the listed ISP 
servers computers. The percentage specified in the list for 
any given server computer may be the same or different 
than for the other servers identified in the list. Preferably 
the percentages should add up to 100%. FIG. 4A, for 
example shows a load balance list in which the load is to 
be divided equally among four ISP server computers 18 
(i.e., ISP servers 1-4). Each server in the list includes 
common data that may be accessed by a client computer. 
In some embodiments, servers may be identified as uplink 
servers, downlink servers or both uplink and downlink 
servers." 
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Ballard discloses a list which appears on a computer which is over time 

the load balance of the list may be refined. 

Swildens discloses the following in Column 17 lines 42-54. 

"A server name, physical location, and network location 
identify each location. For example, the last location in FIG. 
6D is labeled as "server-4/sterling/exodus." This label 
identifies a server on the Exodus network located in 
Sterling, VA., USA. 

After all, the overall timetable, details for each location are 
presented in individual tables. FIG. 5 shows a table 
containing the details for the location "server-14, dc, cw, a 
server located on the Cable & Wireless Network in 
Washington D.C., USA. The IP address of the actual server 
is shown in the heading of the table so you can perform 
additional iests, if needed, (trace route and so on) on the 
actual server performing the test. The location table in FIG. 
6E shows data for the www.speedera.com website." 

Swilden discloses an IP address of the actual server so that additional 
tests may be performed. 

Zisapel discloses the following in col. 4, lines 29 -39. 

"There is also provided in accordance with a preferred 
embodiment of the present invention a network load 
balancing system including a network, at least two load 
balancers connected to the network, and a requestor 
connected to the network, where each of the at least two 
load balancers is operative to determine the network 
proximity of the requestor, and at least one of the load 
balancers is operative to designate a closest one of the load 
balancers by ranking the load balancers by network 
proximity and direct requests from either of the requester 
and a subnet of the requester to the closest load balancer." 

Zisapel uses a load balancer which is connected to the network. 

Neither Ballard, Swildens or Zisapel taken separately or together disclose 
or anticipate the invention claimed by Appellant in claims 1, 9 and 17. The cited 
patents do not disclose or anticipate steps c2) and d) of claims 1, 9 and 17 
namely: accessing said table to retrieve a service provider address associated 
with a service provider location code geographically closest to said retrieved 
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location code so that utilization of the service providers is systematically load 
balanced with respect of the geographic location of the client, and accessing by 
said devices a seed system to download an updated table if said devices cannot 
access the service provider retrieved from said table. 

An advantage of the foregoing claim limitation is that a server that is 
geographically close to the client may be utilized to distribute the work load on a 
geographic basis. 

An additional advantage of Appellant's claim step d is that, Appellant is 
accessing a table on the device, thus the only time Appellant's devices need to 
refer to a seed system is to obtain a new updated table when a device can not 
access the service provider using the address stored on the device. Zisapel 
does not disciose or anticipate the seed system claimed by Appeiiant in step d). 
Zisapel load balancer is involved in every request. Thus, Appellant's claimed 
seed system requires less computer resources and Appellant's devices can 
continue to access the system provider as long as the system providers 
addresses stored in the device table are accurate. 

Notwithstanding the foregoing, in rejecting a claim under 35 U.S.C. 
§103, the Examiner is charged with the initial burden for providing a factual basis 
to support the obviousness conclusion. In re Warner, 379 F.2d 1011, 154 
USPQ 173 (CCPA 1967J; in re Lunsford, 375 F.2d 385, 148 USPQ 721 (CCPA 
1966); in re Freed, 425 F.2d 785, 165 USPQ 570 (CCPA 1970). The Examiner 
is also required to explain how and why one having ordinary skill in the art would 
have been led to modify an applied reference and/or combine applied references 
to arrive at the claimed invention. In re Ochiai, 37 USPQ2d 1127 (Fed. Cir. 
1995); in re Deuel, 51 F.3d 1552, 34 USPQ 1210 (Fed Cir. 1995); in re Fritch, 
972 F.2d 1260, 23 USPQ 1780 (Fed. Cir. 1992); Uniroyal, Inc. v. Rudkin-Wiley 
Corp., 837 F.2d 1044, 5 USPQ2d 1434 (Fed. Cir. 1988). In establishing the 
requisite motivation, it has been consistently held that both the suggestion and 
reasonable expectation of success must stem from the prior art itself, as a whole. 
In re Ochiai % supra : in re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 
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1991); in re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988); in re Dow 
Chemical Co., 837 F.2d 469, 5 USPQ2d 1529 (Fed. Cir. 1988). 

B. Claims 6-7, 13-15 and 21-24 have been rejected by the 
Examiner under 35 USC§1 03(a) as being unpatentable over Ballard (U.S. 
Patent No. 6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,484,143). 

Claim 6 depends on claim 5 and claim 5 depends on claim 1. Claim 13 
depends on claim 9, and claim 21 depends on claim 17. Claims 5, 13 and 21 
include a limitation wherein a group of said service providers share a common 
location code, said device addressing said initiated request to a primary service 
provider in said group, and said device being further programmed to address 
said initiated request to an alternate service provider in said group if said device 
cannot log on to said primary service provider. 

The Examiner stated in page 8 of the Final Rejection the following: 
"Ballard teaches an emergency back-up load balance list (table) whereas a client 
computer is unable to access any of the servers in the normal load balance table 
(primary or alternate). See col. 6, lines 10-29. See also Rune col. 1, lines 57-63. 

Ballard discloses the following in column 6 lines 8 - 29; 

"The percentage specified in the list for any given server 
computer may be the same or different than for other servers 
identified in the list. Preferably the percentages should add 
up to 100%. Fig. 4A, for example shows a load balance list 
in which the load is to be divided equally among four ISP 
server computers 18 (i.e., ISP servers 1-4). Each server in 
the list includes common data that may be accessed by a 
client computer. In some embodiments, servers may be 
identified as uplink servers, downlink servers or both uplink 
and downlink servers. 

In some embodiments, each client computer also stores 
an emergency back-up load balance list. This list is used in 
the event that a client computer 14 is unable to connect to 
any of the servers in the normal load balance list. 
Accordingly, at least one of the servers identified in the 
emergency back-up load balance list should differ from the 
servers identified in the normal load balance list. Referring to 
Fig. 5, an exemplary emergency load balance list includes 
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the data owners own computer servers 15 (e.g., ABC 
Company servers 1 and 2). One or more other server 
computers such as an ISP server 18 may be used in addition 
or instead." 

Rune discloses the following in col. 1, lines 54-63. 

"The present invention is a method and Internet system 
that attempts to improve response times by automatically 
selecting for use a server (e.g., mirror server or alternative 
server) located relatively close to a requesting host. More 
specifically, the Internet system can operate to select the 
closest server from a plurality of servers providing the same 
service (e.g., mirror servers) or slightly adapted variants of 
the same service (e.g., alternative servers) each assigned a 
common host name and a unique Internet Protocol address. 
The Internet system includes a database (e.g., Domain 
Name System (DNS) server) for storing the common host 
name and the plurality of unique Internet Protocol 
addresses." 

Swildens discloses the following in column 10, lines 37-65: 

"Latency problems are often aggravated by packet loss. 
Packet loss, common on the Internet, tends to worsen at 
"peering points," locations where different networks connect. 
One way to reduce packet loss and latency is to install 
content servers closer to users and ensure that when a user 
requests data, the request is routed to the closest available 
server. The present network has deployed web caches, 
streaming, and FTP servers throughout the Internet, on 
many networks close to end users. In addition, the network 
uses a Global Traffic Manager that routes traffic to the 
closest, most available and least loaded server. 

The network often synchronizes the content on the 
customer's origin site with the Web cache servers on the 
network. When new content is placed on an origin site and 
when users make requests for that content, it is 
automatically replicated to Web cache servers in the 
network. When new content is published on the origin site 
with a new name, it is generally immediately available from 
all caches in the present network. For example, the network 
user might add an object to the site where a similar object 
exists: 

Add www.customer.com/images/picture2.jpg to the same 
site as "www.customer.com/images/picturejpg." 
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When a request for "picture2.jpg" arrives at a cache the first 
time, the cache in the network determines that it does not 
have a copy of "picture2jpg", and the cache will request a 
copy from the origin site. To keep in synchronization with 
the origin site, the caches periodically check the content they 
have cached against the copy of the content in the origin 
site." 

Swildens discloses the following in column 4, line 62 to column 5, line 16: 

"The present system also uses one or more probes to detect 
information about certain criteria from the network. There 
are probes including a NetProbes, a ServiceProbe and a 
LatencyProbe. ServiceProbes test local server resources 
while LatencyProbes conduct network round trip tests to 
clients. Each POP in ihe network is assigned a 
ServiceProbe and a LatencyProbe - these can be separate 
machines but in most cases, the same machine will perform 
both types of probe. 

The NetProbes are responsible for providing the traffic 
management system with service and latency metrics. The 
metrics are reported to the DNS server and LogServers. 
FIG. 2 is a simplified diagram 200 of these probes according 
to embodiments of the present invention. This diagram is 
merely an example which should not limit the scope of the 
claims herein. One of ordinary skill in the art would 
recognize many variations, alternatives, and modifications. 
The diagram 200 includes a POP 201, which includes a 
NetProbes server. Service probes monitor the POP servers 
to test the availability and load of the services they support. 
The latency probe tests the round trip time between the POP 
and the DNS servers." 

Thus, Swildens redirects the device to connect to a cache. Then the 
device looks for the content on the cache. If the content is missing on the cache, 
the cache retrieves the content from the origin system. 

In addition to the arguments made in above Section A, in Appellant's 
claims 6, 13 and 21 Appellant will try service provider 1 at a location code. If the 
above fails, Appellant will try service provider 2 at the same location code. 

Thus, the cited art does not disclose a limitation wherein a group of said 
service providers share a common location code, said device addressing said 
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initiated request to a primary service provider in said group, and said device 
being further programmed to address said initiated request to an alternate 
service provider in said group if said device cannot log on to said primary service 
provider. 

C. Claims 2, 10 and 18 have been rejected by the Examiner under 
35 USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 
6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,484,143) and further 
in view of Leon (U.S. Patent No. 6,424,954) 

Claim 2 depends on claim 1, claim 10 depend on claim 9 and claim 18 
depends on claim 17. Claims 2, 10 and 18, respectively, claim the network 
device being a mailing device, and a mailing device. 

The Examiner stated in pages 12 of the Final Rejection: 

"On page 5 of the specification, applicant indicates that 
network devices include mailing devices such as postage 
meters and rating scales and on page 3 applicant asserts 
that a mailing device is any device which may know as a 
matter of its operation its geographic address, (emphasis 
added) 

Neither Ballard nor Swildens make specific mention of such 
device. However, in Fig 1A, and col. 1, line 49-col. 2, line 27 
Leon discloses such a device. Thus, it would have been 
obviousat the time of the invention for an artisan of ordinary 
skill in the art to combine the use of client-side load 
balancing as taught by Ballard and the physical location 
code disclosed by Swildens with the mailing device taught by 
Leon. Since a mailing device makes use of zip codes as 
unique identification, it would readily incorporate zip codes 
as a convenient geographic ISP locator." 

In addition to the arguments made in above Section A, claims 2, 10 and 
18, respectively, claim the network device being a mailing device. 



Leon discloses the following in column 1 line 49-column 2 line 27. 
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"The present invention relates to the field of postage 
metering systems, and more particularly to a portable, 
secure, low cost, and flexible postage metering system. 
A postage meter allows a user to print postage or other 
indicia of value on envelopes or other media. Conventionally, 
the postage meter can be leased or rented from a 
commercial group (e.g., Neopost Inc.), The user purchases a 
fixed amount of value beforehand and the meter is 
programmed with this amount. Subsequently, the user is 
allowed to print postage up to the programmed amount. 
Historically, postage meters have been dedicated, stand- 
alone devices, capable only of printing postage indicia on 
envelopes (or labels, in the case of parcels). These devices 
normally reside at a single user location and only provide 
postage metering for that location. Such postage meters 
often require the user to physically transport the device to a 
post office for resetting (i.e., increasing the amount of 
postage contained in the meter). An advance over this 
system is the ability to allow the user to reset the meter via 
codes that are provided by either the manufacturer or the 
postal authority once payment by the user had been made. 
Modem electronic meters are often capable of being reset 
directly by a registered party on-site (at the user's location) 
via communications link. A system that performs meter 
resetting in this manner is known as a Computerized Meter 
Resetting System (or "CMRS"). The party having authority to 
reset the meter and charge the user (usually the 
manufacturer or the postal authority) thus gains access to 
and resets the meter. 

Even with these advancements, postage meters are still, for 
the most part, restricted to use at a single physical location. 
As such devices are dedicated (and rather sophisticated in 
their fail-safe attributes and security), their price tends to be 
prohibitive for small entities. Moreover, the items requiring 
postage must often be brought to the device because of the 
device's physical size and the need for supporting 
connections (i.e., power, communications, and the like). 
As can be seen, a postage metering system that is portable, 
low-cost, secure, and flexible in operation is highly desirable. 
Moreover, a system that centralizes both postage accounting 
and security features is also highly desirable. Such a system 
would allow the printing of postage indicia at locations that 
are convenient to the end-user by allowing the user to take a 
portion of the system to the item in need of postage rather 
than the reverse." 
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Contrary to the Examiner's statement a mailing device does not use a zip 
code as a unique identifier. Many mailing devices are located in each zip code. 
Furthermore, the art cited by the Examiner makes no suggestion that a mailing 
device may be used in step c(2) of independent claims 1, 9, and 17. 



D. Claims 3, 11 and 19 have been rejected by the Examiner under 
35 USC§1 03(a) as being unpatentable over Ballard (U.S. Patent No. 
6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,484,143) and further 
in view of Rabinovich (US Patent No. 6,256,675). 

In addition to the arguments made in above section a, please consider the 



Rabinowich discloses the following in column 7 line29-54; 

"A distance metric is determined for each host at which the 
requested replica is stored, step 203. The distance metric 
measures the cost of communicating between the requester 
and the host. For example, in one embodiment, the distance 
metric is proportional to the latency between the requester 
and the host that stores a replica of the requested object. In 
another embodiment, the distance metric is inversely 
proportionate to the bandwidth of the channel between the 
requester and the host. 

The request distributor selects a host that stores a replica of 
the requested object to respond to the request based upon 
the request metric and the distance metric of the host in 
relation to the request metric and distance metrics of the 
other hosts that also store replicas of the requested object, 
step 204. 

In one embodiment, the request distribution decision as to 
which host to assign the request is made in accordance with 
the method shown in FIG. 3. A host p is identified that stores 
a replica of the requested object and that has the best 
distance metric m in relation to the requester, step 301. For 
example, in one embodiment, the host that is geographically 
closest to the requester will be determined to have the best 
distance metric in relation to the requester. In another 
embodiment, the host which can communicate the least 
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expensively with the requester will be determined to have 
the best distance metric in relation to the requester." 

The art cited by the Examiner does not disclose or anticipate the 
approximate distance between two geographic locations being calculated as a 
function of location codes corresponding to the two locations. 

E. Claims 5, 13 and 21 have been rejected by the Examiner under 
35 USC§ 103(a) as being unpatentable over Ballard (U.S. Patent No. 
6,078,960) in view of Swildens et. al. (U.S. Patent No. 6,481,143) and further 
in view of Rune (US Patent No. 6,304,913). 

In addition to the arguments made in above section A, please consider the 
following: 

Neither Ballard nor Swildens teach a group of said service providers share 
a common location code and selected ones of those of said devices which are 
closest to said group address initiated a request to a primary service provider in 
said group. However, Rune expressly discloses a group of DNS servers linked in 
a hierarchical relationship (functionally equivalent to sharing a common location 
code) and this alternate service provider concept (a DNS is a Service Provider). 
See col. 5, lines 19-37. 

Thus, it would have been obvious at the time of the invention for an artisan 
of ordinary skill in the art to combine the use of client-side load balancing as 
taught by Ballard and the traffic management disclosed by Swildens with the 
group of said service providers share a common location code and selected ones 
of those of said devices which are closest to said group address initiated a 
request to a primary service provider in said group taught by Rune. This system 
would provide for double redundancy thereby insuring QoS with guaranteed 
access to the network." 

Rune discloses the following in lines 6-38 of column 5: 

"Referring to FIG. 2, there is illustrated a simplified flowchart 
of the selection method 200 used to select the closest or 
most appropriate alternative server 158b from the viewpoint 
of the requesting host 152a. Beginning at steps 202 and 
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204, the host name 114 is assigned (step 202) to the set of 
alternative servers 158b and 158e and a unique IP address 
116 is assigned (step 204) to each alternative server so that 
no two alternative servers have the same IP address. For 
example, the set of alternative servers 1586 and 158e can 
have the host name 114 of "mirror servers" and IP 
addresses 116 of "209.180.55.2" (alternative server 1586) 
and "209.180.55.9" (alternative server 158e| 

At step 206, the assigned host name 114 and the unique IP 
addresses 116 are stored in some or all of the look-up tables 
111 of the DNS servers 156a-f56e. The DNS servers 156a- 
156e can be different levels of hierarchy such that one DNS 
server (e.g., DNS server 156a) may not store a particular 
host name and IP address while another DNS server (e.g., 
DNS server 156e) a step lower in the hierarchy may store 
the particular host name and IP addresses. 
At step 208, the requesting host (e.g., requesting host 152a) 
transmits a translation request containing the host name 114 
of the alternative servers 1586 and 158e to one of the DNS 
servers (e.g., DNS server 156a). In the event one of the 
local DNS servers (e.g., DNS server 156a) does not 
recognize the host name 114 transmitted in the translation 
request, then the local DNS server 156a would refer the 
request to another DNS server (e.g., DNS server 156c) 
known as a DNS root server which locates yet another 

DNS server (e.g., DNS server 156e) that is a step lower in 
the hierarchy which may recognize the transmitted host 
name. 



In the invention disclosed by Rune, DNS servers 156a-156e are involved 
at the beginning of the operation. 

The inventions disclosed by Ballard, Swildens and Rune taken separately 
or together, do not disclose or anticipate the invention claimed by Appellant's 
invention in claims 5, 13 and 21. The cited references do not disclose or 
anticipate a group of said service providers sharing a common location code and 
selected ones of those of said devices which are closest to said group address 
initiated a request to a primary service provider in said group; when said selected 
devices addressing said initiated request to an alternate service provider in said 
group if they cannot log on to said primary service provider. 
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In other words, Rune's DNS servers 156a-156e are equivalent to 
Appellant's seed system 34, but are used in a different manner. In Appellant's 
invention, the table is used first. If the information is available in the table, there 
is no need to go to the seed system. The seed system is only used as a last 
resort, when the information from the table is not correct and has to be updated. 
Consequently, Appellant's claimed invention is faster than the inventions 
disclosed by Rune, since Rune's DNS servers 156a-156e handle a larger 
amount of traffic than Applicant's seed system 34, which takes additional time. 

In view of the above Appellant respectfully submits that appealed claims 
1 - 7, 9 -15 and 17 - 27 in this application are patentable. It is requested that the 
Board of Appeal overrule the Examiner and direct allowance of the rejected 
claims. 



Respectfully submitted, 




Ronald Reichman 
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Attorney of Record 
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CERTIFICATE OF MAILING 



PITNEY BOWES INC. 

Intellectual Property and 

Technology Law Department 

35 Waterview Drive 

P.O. Box 3000 

Shelton, CT 06484-8000 



I hereby certify that this correspondence is being deposited with the United States Postal 
Service with sufficient postage as first class mail in an envelope addressed to: 



Mail Stop Appeal Brief-Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 




on May 25, 2006 
Date of Deposit 



Amy Harvey 

Name of Person Certifying 



{10051353.1 } 



25 



VIII. APPENDIX OF CLAIMS INVOLVED IN THE APPEAL 



1 . A method for balancing the load of requests from a plurality of network 
devices for service from a selected one of a plurality of service providers, said 
devices and said service providers being interconnected by a network, said 
method comprising the steps of: 

a) in each of said devices, storing a location code indicative of 
geographic locations of said devices; 

b) in each of said devices, storing a table relating geographic 
location codes and network addresses for said service providers; and 

c) said devices being programmed so that a requesting device 
initiates a request by: 

c1) retrieving said location code for said requesting device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographical location of the 
client 

c3) addressing said initiated request with said retrieved 
service provider address; and 



{10051353.1 ) 



26 



d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

2. The method of claim 1 wherein at least one of said network devices is a 
mailing device. 

3. The method of claim 1 wherein at least an approximate distance between two 
geographic locations can be calculated as a function of location codes 
corresponding to said two locations. 

4. The method of claim 3 wherein said location codes are zip codes used by a 
postal service. 

5. The method of claim 1 wherein a group of said service providers share a 
common location code and selected ones of those of said devices which are 
closest to said group address initiated a request to a primary service provider in 
said group; said method further comprising the step of: said selected devices 
addressing said initiated request to an alternate service provider in said group if 
they cannot log on to said primary service provider. 

6. The method of claim 5 further comprising the step of: said selected devices 
accessing said table to retrieve another service provider address associated with 
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a service provider location code next closest to said retrieved location code if 
they cannot log on to said primary or said alternate service provider. 

7. The method of claim 1 further comprising the step of: said devices accessing 
said table to retrieve another service provider address associated with a service 
provider location code next closest to said retrieved location code if they cannot 
log on to said service provider. 

9. A network device, said device receiving service from a selected one of a 
plurality of service providers when said device and said service providers are 
interconnected by a network, said device comprising: 

a) a first data store storing a location code indicative of said 
device's geographic location; 

b) a second data store storing a table relating geographic location 
codes and network addresses for said service providers; and 

c) said device being programmed to initiate a request by: 

c1 ) retrieving said location code for said device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographic location of the client; 

c3) addressing said initiated request with said retrieved 
service provider address; and 
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d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

10. The device of claim 9 wherein said network device is a mailing device. 

11. The device of claim 9 wherein at least an approximate distance between two 
geographic locations can be calculated as a function of location codes 
corresponding to said two locations. 

12. The device of claim 1 1 wherein said location codes are zip codes used by a 
postal service. 

13. The device of claim 9 wherein a group of said service providers share a 
common location code, said device addressing said initiated request to a primary 
service provider in said group, and said device being further programmed to 
address said initiated request to an alternate service provider in said group if said 
device cannot log on to said primary service provider. 

14. The device of claim 13 wherein said device is further programmed to access 
said table to retrieve another service provider address associated with another 
service provider location code next closest to said retrieved location code if said 
device cannot log on to said primary or said alternate service provider. 
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15. The device of claim 9 wherein said device is further programmed to access 
said table to retrieve another service provider address associated with another 
service provider location code next closest to said retrieved location code if said 
device cannot log on to said service provider. 

17. A network comprising a plurality of network devices and a plurality of service 
providers, said devices receiving service from selected ones of said service 
providers when said devices and said service providers are interconnected by 
said network, said devices each comprising: 

a) a first data store storing a location code indicative of that 
device's geographic location; 

b) a second data store storing a table relating geographic location 
codes and network addresses for said service providers; and 

c) each of said devices being programmed to initiate a request by: 

c1 ) retrieving said location code for said device; 

c2) accessing said table to retrieve a service provider 
address associated with a service provider location code geographically closest 
to said retrieved location code; so that utilization of the service providers is 
systematically load balanced with respect to the geographic location of the client. 

c3) addressing said initiated request with said retrieved 
service provider address; and 
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d) accessing by said devices a seed system to download an 
updated table if said devices cannot access the service provider retrieved from 
said table. 

18. The network of claim 17 wherein at least one of said devices is a mailing 
device. 

19. The network of claim 17 wherein at least an approximate distance between 
twn nponraohic locations can be calculated as a function of location codes 

— — c/- — - • - . . .__ 

corresponding to said two locations. 

20. The network of claim 19 wherein said location codes are zip codes used by 
a postal service. 

21. The network of claim 17 wherein a group of said service providers share a 
common location code, selected ones of those of said devices which are closest 
to said group addressing said initiated request to a primary service provider in 
said group; said selected devices being further programmed to address said 
initiated request to an alternate service provider in said group if they cannot log 
on to said primary service provider. 

22. The network of claim 21 wherein said selected devices are further 
programmed to access said table to retrieve another service provider address 
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associated with another service provider location code next closest to said 
retrieved location code if they cannot log on to said primary or said alternate 
service provider. 

23. The network of claim 17 wherein said devices are further programmed to 
access said table to retrieve another service provider address associated with 
another service provider location code next closest to said retrieved location 
code if they cannot log on to said service provider. 

24. The network of claim 17 wherein said devices are further programmed to 
access a seed system to download an updated table if said table becomes 
invalid. 

25. The method of claim 1 , wherein the location code is a zip code. 

26. The method of claim 9, wherein the location code is a zip code. 

27. The method of claim 17, wherein the location code is a zip code. 
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IX EVIDENCE APPENDIX 

There is no additional evidence to submit. 



{10051353.1 } 



33 



X RELATED PROCEEDING APPENDIX 

There are no related proceedings. 
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